Tech Arsenal 1

home *** CD-ROM | disk | FTP | other *** search

/ Tech Arsenal 1 / Tech Arsenal (Arsenal Computer).ISO / tek-20 / nosvw304.zip / NOSGAS.ZIP / PUBLIC / NOSVIEW / ATTACH < prev next >

Wrap

Text File | 1992-12-31 | 27KB | 648 lines

====== NOSview [301] attach ====== This section details the 'attach' commands for the various hardware and software interface drivers. Not all of these drivers may be configured into every NOS release. A list of the available types on a particular release may be obtained with the 'attach ?' command. Some parameters are accepted by several drivers. They are: --------- <bufsize> --------- For asynchronous devices (e.g. COM ports operating in SLIP or NRS mode) this parameter specifies the size of the receiver's ring buffer. It should be large enough to hold incoming data at full line speed for the longest time that the system may be busy in MS-DOS or the BIOS doing a slow I/O operation (e.g. to a floppy disk). A kilobyte is usually more than sufficient. For synchronous devices (e.g. the scc, hs, pc100, hapn and drsi interfaces operating in HDLC mode), the <bufsize> parameter specifies the largest frame that may be received on the interface. This should be set by mutual agreement among stations sharing the channel, and it is important that it is set correctly. To do this, you must know the size of the largest possible frame that can be received. The AX.25 'paclen' parameter controls only the size of the data field in an I-frame and not the total size of the frame as it appears on the air. The AX.25 specification allows up to 8 digipeaters, so the largest possible frame is 'paclen'+72 bytes. You should make <bufsize> at least this large. So for standard AX.25 with a maximum I-frame data size of 256 bytes, <bufsize> should be at least 328 (i.e. 256+72). A suggested value of 1024 bytes will therefore provide an adequate safety margin. On higher speed channels (e.g. 56kb/s) larger values (e.g. 2K bytes) will provide much better performance and allow full-sized Ethernet packets to be carried without fragmentation. Another important consideration is that the more recent versions of NOS improve interrupt response by maintaining a special pool of buffers for use by the receive routines. These buffers are currently fixed in size to 2048 bytes and this can be changed only by editing "config.h" and recompiling NOS. This limits <bufsize>; in fact, attempting to set a larger value may cause the driver not to work at all. This situation can be detected by running the memory status command and looking for a non-zero count of "Ibuffail" events, although these events can also occur occasionally during normal operation. ----------- <interface> ----------- The name (an arbitrary character string) to be assigned to this interface. It is used to refer to the interface by many other commands, including: axc25 bc dialer rarp bbs Gateway ifconfig route comm mode tip connect netrom trace detach param ----------- <ioaddress> ----------- The base address of the interface's control registers, in hexadecimal. ----- <mtu> ----- The Maximum Transmission Unit (MTU) size, in bytes. Datagrams larger than this limit will be fragmented at the IP layer into smaller pieces. IP-level fragmentation often makes it possible to interconnect two dissimilar networks, but it is best avoided whenever possible. One reason is that when a single IP fragment is lost, all other fragments belonging to the same datagram are effectively also lost and the entire datagram must be retransmitted by the source. Even without loss, fragments require the allocation of temporary buffer memory at the destination, and it is never easy to decide how long to wait for missing fragments before giving up and discarding those that have already arrived. A reassembly timer controls this process. (See the 'ip rtimer' command). Most subnetworks that carry IP have MTUs of 576 bytes or more, so interconnecting them with subnetworks having smaller values can result in considerable fragmentation. For this reason, IP implementors working with links or subnets having unusually small packet size limits are encouraged to use transparent fragmentation, that is, to devise schemes to break up large IP datagrams into a sequence of link or subnet frames that are immediately reassembled on the other end of the link or subnet into the original, whole IP datagram without the use of IP-level fragmentation. Such a scheme is provided in AX.25 Version 2.1. It can break a large IP or NET/ROM datagram into a series of 'paclen' sized AX.25 segments (not to be confused with TCP segments), one per AX.25 I-frame, for transmission and reassemble them into a single datagram at the other end of the link before handing it up to the IP or NET/ROM module. The segmentation procedure is a new feature in AX.25 and is unfortunately not yet widely implemented; in fact, NOS is so far the only known implementation. This creates some inter- operability problems between NOS and non-NOS nodes; in particular, standard NET/ROM nodes being used to carry IP datagrams. For AX.25 UI-frames, MTU limits the size of the information field. For AX.25 I-frames, however, the AX.25 'paclen' parameter is also relevant. If the datagram or fragment is still larger than 'paclen', it is also fragmented at the AX.25 level (as opposed to the IP level) before transmission. See the 'ax25 paclen' command for further information. Each fragment of a datagram has its own IP header, and is handled by the network as if it were a distinct IP datagram. When it arrives at the destination it is held by the IP layer until all the other fragments belonging to the original datagram have arrived. Then they are reassembled back into the complete, original IP datagram. The minimum acceptable interface MTU is 28 bytes: 20 bytes for the IP header, plus 8 bytes of data. There is no default MTU in NOS; it must be explicitly specified for each interface as part of the 'attach' command. TCP/IP header overhead considerations similar to those of the AX.25 layer when setting 'paclen' apply when choosing an MTU. However, certain subnetwork types supported by NOS have well- established MTUs, and these should always be used unless you know what you're doing. The recommended MTUs for these network types are: Ethernet: 1500 bytes ARCNET: 508 bytes PPP: The MTU for PPP is automatically negotiated, and defaults to 1500 bytes. Other subnet types, including SLIP and AX.25, are not as well standardized. SLIP: Has no official MTU, but the most common implementation (for BSD UNIX) uses an MTU of 1006 bytes. Although NOS has no hard-wired limit on the size of a received SLIP frame, this is not true for other systems. Interoperability problems may therefore result if larger MTUs are used in NOS. AX.25: Choosing an MTU for an AX.25 interface is more complex. When the interface operates in datagram (UI-frame) mode, the 'paclen' parameter does not apply. The MTU effectively becomes the 'paclen' of the link. However, as mentioned earlier, large packets sent on AX.25 connections are automatically segmented into I-frames no larger than 'paclen' bytes. Unfortunately, as also mentioned earlier, NOS is so far the only known implementation of the new AX.25 segmentation procedure. This is fine as long as all of the NET/ROM nodes along a path are running NOS, but since the main reason NOS supports NET/ROM is to allow use of existing NET/ROM networks, this is unlikely. So it is usually important to avoid AX.25 segmentation when running IP over NET/ROM. The way to do this is to make sure that packets larger than 'paclen' are never handed to AX.25. A NET/ROM transport header is 5 bytes long and a NET/ROM network header takes 15 bytes, so 20 bytes must be added to the size of an IP datagram when figuring the size of the AX.25 I-frame data field. If 'paclen' is 256, this leaves 236 bytes for the IP datagram. This is the default MTU of the "netrom" pseudo-interface, so as long as 'paclen' is at least 256 bytes, AX.25 segmentation can't happen. But if smaller values of 'paclen' are used, the netrom MTU must also be reduced with the 'ifconfig' command. On the other hand, if you're running IP directly on top of AX.25, chances are all of the nodes are running NOS and support AX.25 segmentation. In this case there is no reason not to use a larger MTU and let AX.25 segmentation do its thing. If you choose an MTU on the order of 1000-1500 bytes, you can largely avoid IP-level fragmentation and reduce TCP/IP-level header overhead on file transfers to a very low level. And you are still free to pick whatever 'paclen' value is appropriate for the link. ------- <speed> ------- The speed on the NOS serial link (e.g. between the computer running NOS and the TNC) in bits per second (e.g. 4800). -------- <vector> -------- The interface's hardware interrupt (IRQ) vector, in hexadecimal. The individual 'attach' commands are now described: _________________________________________________________________ attach 3c500 <ioaddress> <vector> arpa <interface> <qlen> <mtu> [<ipaddr>] _________________________________________________________________ THIS COMMAND IS NOW OBSOLETE. Attach a 3Com 3C501 Ethernet interface. <qlen> is the maximum allowable transmit queue length. If the <ipaddr> parameter is not given, the value associated with a prior ip address command will be used. The use of this driver is not recommended; use the 'packet' driver interface with the loadable 3C501 packet driver instead. >> Example: attach 3c500 0x300 3 arpa en0 5 1500 _________________________________________________________________ attach asy <ioaddress> <vector> ax25 | nrs | ppp | raw | slip <interface> <buffers> <mtu> <speed> [<slip_options>] _________________________________________________________________ Attach a standard PC COM port (asynchronous serial port), using the National 8250 or 16550A chip. Standard values on the IBM PC and clones for <ioaddress> and <vector> are as follows: COM1: 0x3f8 and 4 COM2: 0x2f8 and 3 If the port uses a 16550A chip, it will be detected automatically and the FIFOs enabled. _________________________________________________________________ attach asy <ioaddress> <vector>[c] ax25 <interface> <buffers> <mtu> <speed> _________________________________________________________________ Encapsulate IP datagrams within an AX.25 frame and precede with a KISS data header before SLIP encoding. Either UI- (connectionless) or I- (connection-oriented) AX.25 frames can be used; see the 'mode' command for details. By default, IP datagrams are sent in UI-frames. NOS can in theory support as many serial ports as you can fit on the machine. It does support shared interrupts, although you have to specify this by appending the suffix 'c' (chain) to the IRQ <vector> number in the 'attach' line. This tells the driver's interrupt vector to jump to the vector previously installed on that IRQ number when the handler is the 'attach' line. This tells the driver's interrupt vector to jump to the vector previously installed on that IRQ number when the handler is done. When you attach a series of devices on the same interrupt vector, the last one attached is the first one called when the interrupt occurs. ******* You must give the 'ax25 mycall' command BEFORE attaching ******* the interface. >> Example: To attach the COM2 port to operate in AX.25 mode with an MTU of 576 bytes at 4800 bits/sec with a KISS TNC, calling it 'tnc0': ax25 mycall NS9BOB-5 attach asy 0x2f8 3 ax25 tnc0 1024 576 4800 _________________________________________________________________ attach asy <ioaddress> <vector> nrs <interface> <buffers> <mtu> <speed> _________________________________________________________________ Use the NET/ROM asynchronous framing technique for communication with a local NET/ROM TNC. >> Example: attach asy 0x3f8 4 nrs nr0 1024 576 4800 _________________________________________________________________ attach asy <ioaddress> <vector> ppp <interface> <buffers> <mtu> <speed> _________________________________________________________________ Point-to-Point-Protocol. Encapsulates datagrams in an HDLC-like frame. This is a new Internet standard for point-to-point communication, compatible with CCITT standards. >> Example: _________________________________________________________________ attach asy <ioaddress> <vector> raw <interface> <buffers> <mtu> <speed> _________________________________________________________________ Raw serial line without protocol, special for lpd server. >> Example: _________________________________________________________________ attach asy <ioaddress> <vector> slip <interface> <buffers> <mtu> <speed> [<slip_options>] _________________________________________________________________ Serial Line Internet Protocol. Encapsulates IP datagrams directly in SLIP frames without a link header. This is for operation on point-to-point lines and is compatible with 4.2BSD UNIX SLIP. The <slip_options> are the characters 'c', 'r' and 'v': 'c' enables RTS/CTS detection 'r' enables RLSD (Carrier Detect) physical line sensing 'v' enables Van Jacobson TCP/IP Header Compression >> Example: To attach the COM1 port to operate in point-to-point slip mode at 9600 baud, calling it 'sl0'. A 1024-byte receiver ring buffer is allocated. Outgoing packets larger than 256 bytes are fragmented. RTS/CTS and carrier detection are used, together with header compression: attach asy 0x3f8 4 slip sl0 1024 256 9600 crv _________________________________________________________________ attach axip <interface> <mtu> <their_host> <my_axip_callsign> _________________________________________________________________ This creates an RFC1226-compatible AX.25 frame encapsulator for "wormhole" transmission of AX.25 frames over the Internet. The wormhole appears to the AX.25 level as two digipeaters. The parameter <their_host> is the Internet node name or IP address of the remote system at the other end of the wormhole. The parameter <my_axip_callsign> is the AX.25 callsign this station is listening out for, for frames to digipeat. Note that each attached axip interface should have a different callsign to listen to, and this should also be different from other callsigns used by this station. For example, consider the scenario in the diagram below. NS9BOB and NS9JIM are at opposite ends of an Internet wormhole, in this case represented by an Ethernet link. Bob and Jim decide to use SSID -11 for their axip callsigns. Stations AX9AAA and AX9BBB are ordinary AX.25 stations which wish to communicate via the wormhole. ___________________ ___________________ | | | | axip: | NS9BOB-11 .... | | .... NS9JIM-11 | | : : | | : : | IP: | ns9bob : | | : ns9jim | | : : | Internet Wormhole | : : | ax25: | NS9BOB-5 en0 ==========>============ en0 NS9JIM-5 | | : | AX9AAA>AX9BBB | : | |____:____________| v NS9BOB-5* NS9JIM-5|____________:____| :tnc0 tnc0: : : _____:____ ____:_____ | | | | | AX9AAA | | AX9BBB | |________| |________| CONNECT AX9BBB V NS9BOB-11 NS9JIM-5 AX9AAA>AX9BBB v NS9BOB-5* NS9JIM-11* To implement this setup, Bob requires the following NOS commands in his AUTOEXEC.NOS file: ----------------------------------------------------------------- ax25 mycall NS9BOB-5 attach asy 0x3f8 4 ax25 tnc0 1024 576 4800 ip address ns9bob route add ns9jim en0 arp add ns9jim ether 00:11:22:33:44:55 attach axip ai0 256 ns9jim NS9BOB-11 ----------------------------------------------------------------- That is, in addition to the usual commands for setting up the tnc0 AX.25 interface, an IP 'route' command and an 'arp add' command are needed for the Ethernet wormhole, and the 'attach axip' command is required to implement AX.25 encapsulation. Note that in Bob's 'attach axip' command, the hostname (ns9jim) is the name of the FAR end of the wormhole, and the axip callsign (NS9BOB-11) is that of the LOCAL station. Jim's NOS entries will, of course, be a mirror image of Bob's. Everything is now ready for AX9AAA to connect to AX9BBB. The format of the connect command is: ----------------------------------------------------------------- CONNECT <destination> VIA <local_axip_call> <remote_ax25_mycall> ----------------------------------------------------------------- Thus in this scenario, AX9AAA gives the command: CONNECT AX9BBB VIA NS9BOB-11 NS9JIM-5 NS9BOB is listening for digipeater callsign NS9BOB-11. On hearing this connect request, the axip code then converts NS9BOB- 11 to NS9BOB-5. This is in readiness for the return trip. In addition, the "Has-been-digipeated" bit (indicated by an asterisk in the diagram) is set. The frame is then encapsulated in an IP packet and transmitted across the wormhole to Jim. On arrival at NS9JIM, the axip code now de-capsulates the AX.25 frame, and converts the second digipeater address (NS9JIM-5) to NS9JIM-11, also setting the "Has-been-digipeated" bit. Finally the AX.25 frame emerges from NS9JIM, and arrives at AX9BBB with digipeater addresses NS9BOB-5 and NS9JIM-11. After reversing the callsign order in the usual way, this is exactly what is required for the return trip to AX9AAA via the wormhole. _________________________________________________________________ attach drsi <ioaddress> <vector> ax25 <interface> <bufsize> <mtu> <ch_a_speed> <ch_b_speed> _________________________________________________________________ N6TTO driver for the Digital Radio Systems PCPA 8530 card. Since there are two channels on the board, two interfaces are attached. They will be named <interface> with 'a' and 'b' appended. <bufsize> is the receiver buffer size in bytes; it must be larger than the largest frame to be received. <ch_a_speed> and <ch_b_speed> are the speeds, in bits/sec, for the A and B channels respectively. _________________________________________________________________ attach eagle <ioaddress> <vector> ax25 <interface> <bufsize> <mtu> <speed> _________________________________________________________________ WA3CVG/NG6Q driver for the Eagle Computer card (Zilog 8530). _________________________________________________________________ attach hapn <ioaddress> <vector> ax25 <interface> <bufsize> <mtu> csma | full _________________________________________________________________ KE3Z driver for the Hamilton Amateur Packet Network adapter (Intel 8273). The 'csma|full' parameter specifies whether the port should operate in carrier sense multiple access (CSMA) mode or in full duplex. _________________________________________________________________ attach hs <ioaddress> <vector> ax25 <interface> <bufsize> <mtu> <key_up_delay> <p> _________________________________________________________________ Attach a DRSI PCPA or Eagle Computer interface card using a special "high speed" 8530 driver. This driver uses busy-wait loops to send and receive each byte instead of interrupts, making it usable with high speed modems (such as the WA4DSY 56kb/s modem) on slow systems. This does have the side effect of "freezing" the system whenever the modem transmitter or receiver is active. This driver can operate only in CSMA mode, and it is recommended that no other interfaces requiring small interrupt latencies be attached to the same machine. The <key_up_delay> parameter specifies the transmitter keyup delay in byte time intervals. The <p> value specifies the transmitter persistence value in the range 1-255; the corresponding slot time is fixed at one hardware clock tick, about 55 ms on the PC. As with the other 8530 drivers, this driver actually attaches two interfaces, one for each 8530 channel. _________________________________________________________________ attach kiss <existing_asy_interface> <port> <interface> [<mtu>] _________________________________________________________________ The 'attach kiss' command enables a multiplexed TNC type to be used for second channel. It is used to connect a second port to an already attached 'asy' interface. It will copy most of the parameters of its parent port. >> Example: attach kiss tnc0 2 tnc1 _________________________________________________________________ attach netrom _________________________________________________________________ Pseudo-driver for use with NET/ROM. _________________________________________________________________ attach packet <vector> <interface> <txqlen> <mtu> _________________________________________________________________ Driver for use with separate software packet drivers meeting the Packet Driver specification from FTP Software Inc. The driver must have already been installed before the 'attach' command is given. Packet drivers in the Ethernet, ARCNET, SLIP, SLFP, and KISS/AX.25 classes are supported. <vector> is the software interrupt vector used for communication to the packet driver, and <txqlen> is the maximum number of packets that will be allowed on the transmit queue. >> Example: In AUTOEXEC.BAT, the driver for a Western Digital WD8003E Ethernet adapter can be installed with the command: WD8003E 0x60 2 0x240 0xd000 This means that the adapter uses software interrupt vector 0x60, IRQ 2, I/O address 0x240 and RAM base address 0xd000. Then the NOS packet driver can be attached to the adapter driver with the command: attach packet 0x60 en0 8 1500 _________________________________________________________________ attach pc100 <ioaddress> <vector> ax25 <interface> <bufsize> <speed> _________________________________________________________________ Driver for the PACCOMM PC-100 (Zilog 8530) card. Only AX.25 operation is supported. _________________________________________________________________ attach pi _________________________________________________________________ DMA-driven 8530 scc board from VE3IFB. _________________________________________________________________ attach scc <devices> init <addr> <spacing> <Aoff> <Boff><Dataoff> <intack> <vec> [p|r]<clock> [<hardware_type>] [<param>] _________________________________________________________________ PE1CHL driver to initialize a generic SCC (8530) interface board prior to actually attaching it. The parameters are as follows: <devices> The number of SCC chips to support. <addr> The base address of the first SCC chip (hex). <spacing> The spacing between the SCC chip base addresses. <Aoff> The offset from a chip's base address to its channel A control register. <Boff> The offset from a chip's base address to its channel B control register. <Dataoff> The offset from each channel's control register to its data register. <intack> The address of the INTACK/Read Vector port. If none, specify '0' to read from RR3A/RR2B. <vec> The CPU interrupt vector for all connected SCCs. <clock> The clock frequency (PCLK/RTxC) of all SCCs in hertz. Prefix with 'p' for PCLK, 'r' for RTxC clock (for baudrate generation). <hardware_type> Optional hardware type code. The following values are currently supported: 1: Eagle card 2: PACCOMM PC-100 4: PRIMUS-PC card (DG9BL) 8: DRSI PCPA card. <param> Optional extra parameter. At present, this is used only with the PC-100 and PRIMUS-PC cards to set the modem mode. The value 0x22 is used with the PC-100 and 0x2 is used with the PRIMUS-PC card. The 'attach scc ... init' command must be given before the interfaces are actually attached with the following command. _________________________________________________________________ attach scc <chan> slip|kiss|nrs|ax25 <interface> <mtu> <speed> <bufsize> [<callsign>] _________________________________________________________________ Attach an initialized SCC port to the system. The parameters are as follows: <chan> The SCC channel number to attach, 0 or 1 for the first chip's A or B port, 2 or 3 for the second chip's A or B port, etc. slip | kiss | nrs | ax25 The operating mode of the interface. 'slip', 'kiss' and 'nrs' all operate the port hardware in asynchronous mode: 'slip' is Internet-standard serial line IP mode. 'kiss' generates SLIP frames containing KISS TNC commands and AX.25 packets. 'nrs' uses NET/ROM local serial link framing conventions to carry NET/ROM packets. 'ax25' puts the interface into synchronous HDLC mode that is suitable for direct connection to a half duplex radio modem. <speed> The interface speed in bits per second (e.g. 1200). Prefix with 'd' when an external divider is available to generate the TX clock. When the clock source is PCLK, this can be a /32 divider between TRxC and RTxC. When the clock is at RTxC, the TX rate must be supplied at TRxC. This is needed only for full duplex synchronous operation. When this arg is given as 'ext', the transmit and receive clocks are external, and the internal baud rate generator (BRG) and digital phase locked loop (DPLL) are not used. _________________________________________________________________ attach slfp _________________________________________________________________ Attach the Serial Line Framing Protocol packet driver.